Automatic hierarchical categorization of music by metadata

ABSTRACT

A method, performed by software executing on the processor of a portable music playback device, that automatically files tracks according to hierarchical structure of categories to organize tracks in a logical order. A user interface is utilized to change the hierarchy, view track names, and select tracks for playback or other operations. The user interface uses an overlapping hierarchy of categories. A song title can be accessed in multiple different ways by starting with different categories. A preferred embodiment of the invention uses the top-level categories “Albums”, “Artists”, “Genres” (or styles), and “Play Lists”. Within the Albums category are names of different albums of songs stored in the device. Within each album are the album tracks, or songs, associated with that album. Navigation is performed by presenting a sequence of display screens for each level of the hierarchy.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application is a continuation of application Ser. No. 09/755,723,entitled AUTOMATIC HIERARCHICAL CATEGORIZATION OF MUSIC BY METADATA, andfiled on Jan. 5, 2001, the specification of which is incorporated hereinby reference for all purposes. This application is related toapplication Ser. No. 09/755,629, entitled “System for Selecting andPlaying Songs in a Playback Device with a Limited User Interface,” nowabandoned (Atty. Docket No. 17002-020800); and application Ser. No.09/755,367, entitled “Audioplayback Device with Power Savings StorageAccess Mode,” issued as U.S. Pat. No. 6,590,730 (Atty. Docket No.17002-022400), all filed January 5, 2001, the disclosures of which areincorporated herein by reference in their entirety.

BACKGROUND OF THE INVENTION

Today, portable consumer electronic devices are more powerful than ever.For example, small, portable music playback devices can store hundreds,even thousands, of compressed songs and can play back the songs at highquality. With the capacity for so many songs, a playback device canstore many songs from different albums, artists, styles of music, etc.

Music jukeboxes implemented in software executed by a digital computerand portable MP3 and CD players both provide facilities for formingplaylists. For example, the OOZIC player, distributed by the assignee ofthe present application, runs on a host PC and has a playlist featurethat allows selection of tracks from the PC's hard disk to be includedin the playlist.

As storage capacity increases and songs are compressed to shorter filelengths the number of songs that can be stored increases rapidly. Majorproblems facing the consumer are organizing and accessing the tracks.

Typically, portable devices have a user interface including a smallscreen and buttons. Such a display screen might be, e.g., 1″×2″. Thissmall display size is necessary because of the physical size of thedevice which is typically carried in the hand. The small size alsolimits the number, size, shape, and types of user input controls thatcan be mounted on the device. For example, a few pushbuttons are usuallyprovided to perform all of the device's control functions. Using such acompact user interface to navigate and select among hundreds of songs isinefficient and often frustrating. The display screen can only show afew song titles at one time, and the limited controls make it difficultfor a user to arbitrarily select, or move among, the songs.

The creation of playlists is one technique to organize the playing ofsongs. A set of songs can be included in a playlist which is given aname and stored. When the playlist is accessed, the set of songs can beplayed utilizing various formats such as sequential play or shuffle.

However, the creation of playlists itself becomes problematic as thenumber of songs increases, since the user often arbitrarily selectssongs from a large number of tracks to form a playlist. This selectionmechanism: can be fairly tedious; does not necessarily produce playliststhat are of interest to the user over the course of time; may not remainup-to-date if new songs are added that logically fit into a previouslycreated playlist (e.g. “Favorites by Band X” might become out of date ifa new favorite by Band X is added after the playlist was created); andleads to “lost” songs that are not members of any playlist.

Accordingly, improved techniques for organizing and grouping tracksuseful in a portable music player are needed. Further, it is desirableto provide a user interface suitable for a small device. The userinterface should allow a user to efficiently navigate among, and selectfrom, many items stored in the device.

SUMMARY OF THE INVENTION

The present invention provides an efficient user interface for a smallportable music player. The invention is suitable for use with a limiteddisplay area and small number of controls to allow a user to efficientlyand intuitively navigate among, and select, songs to be played. By usingthe invention, very large numbers of songs can be easily accessed andplayed.

One aspect of the invention includes an overlapping hierarchy ofcategories. Categories include items that can also be included in othercategories so that the categories “overlap” with each other. Thus, asong title can be accessed in multiple different ways by starting withdifferent categories. For example, a preferred embodiment of theinvention uses the top-level categories “Albums”, “Artists”, “Genres”(or styles), and “Play Lists”. Within the Albums category are names ofdifferent albums of songs stored in the device. Within each album arethe album tracks, or songs, associated with that album. Similarly, theArtists category includes names of artists which are, in turn,associated with their albums and songs. The Genre category includestypes of categories of music such as “Rock”, “Hip Hop”, “Rap”, “EasyListening”, etc. Within these sub-categories are found associated songs.Finally, the “Play Lists” category includes collections of albums and/orsongs which are typically defined by the user.

Advantageous use is made of the overlapping hierarchy to allow the userto quickly designate a song for playback. The device uses three “soft”pushbuttons that have assignable functions. The interface maintainsconsistent button functionality whenever possible and uses uniformcommand names and operations on different types of items so that theinterface is more intuitive. For example, the user can open and queueboth albums and songs with predictable results.

The interface also provides for multiple functions for a single control.For example, a “Play” button can act, in a first function, to play acurrently-selected song. The Play button can act, in a second function,to cycle through different playback modes. The modes can be, e.g., (1)playback of songs from a hard disk; (2) playback of music from a radioreceiver built into the device; and (3) playback of voice messages. Thefirst function for the Play button can be activated by momentarilydepressing the Play button for a short period of time. The secondfunction is invoked by depressing the Play button for a longer period oftime whereupon the device cycles through the different modes. Other waysof invoking the functions are possible such as where the second functionis automatically entered from a powered-down state.

In one embodiment, the invention provides a method for selecting songsto be played in an electronic audio device, wherein the device includesa display and one or more user input controls, wherein songs areorganized into categories, albums, wherein songs and albums areassociated with artist names. The method includes steps of displayingcategories on the display; accepting signals from a user input controlto select a category; displaying one or more songs in the selectedcategory on the display; accepting signals from a user input control toselect a displayed song; and entering selected songs into a playlistqueue, wherein the device plays back songs in the playlist queue.

According to one aspect of the present invention, a technique isprovided for organizing tracks on a portable music player byautomatically filing tracks in a hierarchical order based on attributesof the tracks.

According to another aspect of the invention, metadata is associatedwith each track that is used to automatically define the track'sappropriate place in the hierarchy.

According to another aspect of the invention, the hierarchy is displayedon the portable music player so that a user can traverse theorganizational hierarchy to find individual tracks or find playlistscomposed of logical groups of tracks.

According to another aspect of the invention, the hierarchy is derivedby using metadata associated with the audio content that was obtainedthrough any source of metadata (e.g. CDDB metadata, id3v2 metadata,other obtainable metadata) and subsequently stored with or alongside thefile that stores the track.

According to another aspect of the invention, a file is formatted sothat an unaltered track is stored as file data and information about thetrack is stored in file attribute files.

Other features and advantages of the invention will be apparent in viewof the following detailed description and appended drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram of a tree structure for hierarchicalfiling of tracks;

FIG. 2 is a definition file that specifies the hierarchy depicted inFIG. 1;

FIG. 3 is a user's view of the hierarchy;

FIG. 4 is a schematic diagram of a user interface displaying thehierarchical category structure;

FIG. 5 is a diagram of a file format for storing filed data and fileattributes;

FIG. 6 is a flow chart depicting steps for filing tracks according tothe hierarchical tree structure;

FIG. 7 depicts a tree resulting from searching the tracks;

FIG. 8 depicts a format for a user interface;

FIG. 9 illustrates the NOMAD Jukebox and its user interface controls;

FIG. 10 illustrates a sequence of display screens describing how tonavigate to lower levels;

FIG. 11 illustrates associations among items;

FIG. 12 shows display screens used to search for a song or other item;

FIG. 13 illustrates details of different items; and

FIG. 14 illustrates a playback device coupled to a host computer system.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

A preferred embodiment of the invention will now be described in thecontext of a portable personal player that plays audio files stored inmemory. The files may be in MP3, wav. or other digital formats.

In the presently described embodiment, users are able to see the trackson their player in some organized fashion other than as a single list oftracks. As will be described in more detail below, in one embodimenttracks are sorted utilizing a tree structure having branches labeledaccording to types of metadata associated with the tracks

For example, a track recorded as “Golden Slumbers” by the Beatles thatappears on their album “Hey Jude” might appear as a track under thealbum “Abbey Road” as well as a track under the list of tracks by theBeatles. It might appear as a track under the genre “Pop Rock” as wellas “Songs from the 60's.” Furthermore, the organization can have morecomplex hierarchies. For example, the category of “Pop Rock” mightcontain subcategories “British Musicians,” “American Musicians” and“Other Musicians”. In all cases, the track is automatically filed intoall appropriate locations without requiring user interaction.

In the currently defined embodiment, a tree structure is defined by afile having the following structure.

The first line of a TreeDef.inf file contains a version number:

-   -   V1.0

Each subsequent line (at least in v1.0) contains lines of the followingformat:

-   -   CATEGORY_NAME|TRACK_TYPE_MASK|CATEGORY_STRUCTURE    -   CATEGORY_NAMEs are the top-level names of the branch under which        tracks are sorted. They include things like “Album,” “Artist,”        “Voice Tracks,” “All Tracks,” etc.

TRACK_TYPE_MASKs tell which types of tracks are to be filed under thisparticular branch. The actual value is a hexadecimal numerical value (in‘0×’ format, e.g. 0×01) generated by ORing the following flags togetheras appropriate: enum tTrackType {   kTTNothing=0x00,   kTTSong=0x01,  kTTVoice=0x02,   kTTBook=0x04,   kTTMacro=0x08,   kTTPlaylist=0x10 };

So, for example, the “Album” branch has a TRACK_TYPE_MASK of kTTSong,because only songs are filed under that branch, but the “All Tracks”branch has a TRACK_TYPE_MASK of (kTTSong|kTTVoice|kTTBook).

Other elements might be added to tTrackType (e.g. kTTVideo) asappropriate.

CATEGORY_STRUCTUREs tell how to file the songs based on their metadatainformation. The CATEGORY_STRUCTURE is a string of characters that tell,from left to right, the order of hierarchy. The characters come from thefollowing enum constants: enum tFileTag {   kFTNone=‘@’,  kFTTrackType=‘T’,   kFTTitle=‘N’,   kFTAudioFile=‘F’,   kFTArtist=‘M’,  kFTAlbum=‘L’,   kFTGenre=‘G’,   kFTSource=‘S’,   kFTYear=’Y’,  kFTArtistCountry=’C’ };

Thus, a CATEGORY_STRUCTURE of LN tells to create a subcategory that is alist of Albums, each of which contains a list of Tracks.

In total, a line like:

-   -   Album|0×01|LN

Says to create a branch called “Album” which contains tracks of typekTTSong organized first by album name, and then by track name.

The following is an example of a tree definition file similar (thoughnot identical) to the hierarchy presented in the Nomad Jukebox product(the ‘B’ before each FileTag was used to identify that these are basictags so that we wouldn't run out of letters in the alphabet as weincluded more complex metadata—thus each group of two letters representsa level in the hierarchy):

-   -   V1.0    -   Album|0×01|BLBN    -   Artist|0×01|BMBN    -   Genre|0×01|BGBN    -   Voice Tracks|0×02|BSBGBN    -   Playlists|0×10|BN    -   Macros|0×08|BN    -   All Tracks|0×07|BN

FIG. 1 depicts a hypothetical organization hierarchy. The tree shows howtracks might be listed (as leaves in the tree) after having beenorganized. Example values for nodes in the tree are shown as well. Thesame track may appear more than once as a leaf in the tree, as describedabove, if it fits into multiple categories (e.g. a song that appears onthe Abbey Road branch would also appear in the Beatles branch). In theexample shown, the first branch contains tracks organized by album. Asshown in the example, this music collection contains three tracks from“Abbey Road” and three tracks from “Hits from the 60's”. The secondbranch contains tracks organized by artist, and sub organized by wherethe artist is from. Thus, a user browsing would first select the“Artists” branch and then choose between “British Artists” and “AmericanArtists”. Finally, they would select the particular artist. In the thirdbranch, all tracks are shown.

The tree definition file that would specify the hierarchy shown in FIG.1 is shown in FIG. 2.

The first line identifies the version of the tree definition file.

The second line defines the “Albums” branch. The first part of the line,“Albums” defines the name of the branch. The second part, “0×01,”defines that all musical tracks should be categorized on this branch.The third part, “BLBN,” defines that the branch lists first the names ofall albums (BL) and then tracks on those albums (BN).

The third line defines the “Artists” branch. The first part of the line“Artists” defines the name of the branch. The second part, “0×01,”defines that all musical tracks should be categorized on this branch.The third part, “BCBMBN,” defines that the branch lists first the namesof all countries where artists in this collection come from (BC) andunder those items, the artists' names (BM), and then tracks by thoseartists (BN).

FIG. 3 shows what a user's view of this hierarchy might be if he/shewere shown a fully expanded view of the 6-song tree. Notice that eachsong appears three times, once in each branch.

In consumer products the tree define file is not edited directly butthrough a user interface, one example of which is depicted in FIG. 4. Anexample of a user interface for viewing songs by category and editingthe tree structure is depicted in FIG. 4.

An embodiment of the invention is utilized in the Nomad® Jukebox,manufactured by the assignee of the present invention, and describedmore fully in the copending application, filed on the same date as thepresent application, entitled “System for Selecting and Playing Songs ina Playback Device with a Limited User Interface,” (Attny. Docket No.17002-020800).

In a preferred embodiment, metadata is associated with each track andincludes such information as title, genre, artist name, type, etc. Inthe preferred embodiment, software stored in a portable player andexecuted by the onboard processor automatically files each track in thecorrect category utilizing the associated metadata and the tree definefile. The program code can be stored in any computer readable mediumincluding magnetic storage, CD ROM, optical media, or digital dataencoded on an electromagnetic signal.

Thus, the user is automatically provided with a powerful and flexibletool for organizing and categorizing the tracks stored on the portableplayer.

If the tracks are formatted in MP3 format the metadata can be stored inID3 tags included in the MP3 file. In one embodiment of the invention,the tracks are stored in alternate file format including file data andfile attributes. The file data is the music track itself and the fileattributes part of the file includes fields of arbitrary size which areused to store metadata characterizing the track stored as the file data.Again this metadata includes information about the track such as title,genre, artist name, type, etc.

There are several advantages to using the alternate file format.Metadata of types not easily included in an ID3 tag can be utilized.Further, the original track format is not changed, so that errorcorrection data such as checksums are valid. Finally, any file formatcan be used (e.g. WAV, WMA, etc.) because the metadata is storedseparately, and thus audio formats that have limited support formetadata can still be stored on the portable player in native formatwithout transcoding. The formatted files are formed by software storedin the portable music player and executed by an on-board processor.

The metadata for each track is utilized to file each track, using thecategories defined in the hierarchical structure as described above,without any input from the user.

FIG. 5 is a schematic diagram of the alternative file format includingfile data in the form of an MP3 track, and metadata fields for holdingdata indicating the name of the album the track is from, the name of thesong, the genre of the song, and the type of track.

A particular embodiment of a file format will now be described. Alltracks are created with some set of attributes as shown below:

Definition of TrackInfo Data Field Field Offset Size DescriptionAttribute Count  0 2 The number of attribute follow for the track Attr 1type  2 2 Binary = 0, ASCII = 1 Attr 1 name len  4 2 Length of attributename string Attr 1 data len  6 4 Length of attribute data Attr 1 Name 10N Attribute name string Attr 1 Data 10 + N M Attribute data . . . Attr Ntype Attr 1 name len Attr 1 data len Attr 1 Name Attr 1 Data

Required Attributes Attribute Name Value(s) Remarks TITLE ASCII stringRequired By Jukebox CODEC “MP3”, “WMA”, “WAV” Required By Jukebox TRACKID DWORD Set By Jukebox ALBUM ASCII string Optional ARTIST ASCII stringOptional GENRE ASCII string Optional LENGTH In seconds Optional TRACKSIZE In bytes Optional TRACK NUM 1-n (track within album) Optional

These attributes can be subsequently changeable via a host application,running on a personal computer connected to the portable music player.

FIG. 6 shows a flow chart of an embodiment the process used to build thehierarchical database of tracks. It starts by iterating through eachtrack, and, for each track, iterating through each branch to find if thetrack belongs on the branch, and, if so, where. In this case, the termtrack could refer to any content, e.g. a music track, a spoken wordtrack, or even a video track.

Also, the hierarchical catalog of tracks can be used to form playlistsin a structured manner. For example, if a user wants to hear Jazz andBlues the entire sub-categories can be selected to form one playlist.

An alternative hierarchical catalog generation technique will now bedescribed. In this alternative embodiment, at system startup and astracks are added or changed, the hierarchy is generated as an in-memorytree structure. Each track is added to the tree using the categoriesALBUM, ARTIST and GENRE.

The following example shows the algorithm for adding a track. Forclarity, only the attributes used by the tree are shown. TITLE “FreeFalling” ALBUM “Full Moon Fever” ARTIST “Tom Petty” GENRE “Rock” TRACKNUM 1

The following function is executed to build the in-memory memory tree.Build Tree ( ) For each track,   Add Track To Category(Album, Track)  Add Track To Category(Artist, Track)   Add Track ToCategory(Genre,Track) End of Build Tree

FIG. 7 depicts a tree which could result from implementing Build Tree( )function. Note that “Stardust” does not have any entries for Album orArtist. The host software running on a computer connected to theportable music player could be utilized to add missing attributes to the“Stardust” track and, optionally, edit the title attribute. The BuildTree( ) function would then reinsert this track in the correct locationin the tree.

FIG. 8 is an embodiment of a user interface according to anotherembodiment of the invention. In this example the root node is labeled“My Configuration” and the Playlist category has been selected and thePlaylist subcategory “Meddle” has been selected. Note that the types ofMetadata, in this example, Track Name, Artist, Album, Tempo and Dance,are listed across the top of the screen, and the attribute values foreach track are listed in a row across the screen. Various controlbuttons are displayed to the right of configuration window thatfacilitate quickly invoking selected processing on a selected track.

As noted above, a preferred embodiment of the present invention isincorporated into a product manufactured and distributed by CreativeTechnology, Ltd. The product is called the “NOMAD Jukebox.” Thefollowing description describes further details of the display screensand interface controls.

FIG. 9 illustrates the NOMAD Jukebox and its user interface controls.

In FIG. 9, electronic audio device 100 measures about 5.5″ wide by 5.5″tall by 1″ thick. Display screen 102 is about 2″ wide by 1″ tall.Display screen 102 includes different regions such as main region 104and soft button function description region 106.

Three soft buttons are located at 108; including buttons 110, 112 and114. The specific command, or function, that any of the soft buttonsperform when depressed is indicated by the label in soft button functiondescription region 106. Thus, the function of soft button 112 (as shownin FIG. 9) is “open,” the function of soft button 114 is “search” whilesoft button 110 is currently not assigned a function.

The other eight buttons on device 100 perform essentially the samefunctions at all times. In other words, they are not subject to functionchanges according to soft button function description area 106. Thesebuttons include Library button 116, EAX and System button 118, SkipBackward button 120, Play button 122, Stop button 124, Skip Forwardbutton 126, Scroll Up button 128 and Scroll Down button 130. However, asdiscussed below, these buttons (or any type of controls used with thedevice) can include alternate functionality that is invoked in differentways.

The device uses visual cues, or indicators, in the display. When an itemis highlighted it indicates that the item is the “current” item, orcurrently-selected item, which is susceptible to be operated on by asubsequent user action—such as playback, or expansion of the item. InFIG. 1, screen 102 shows that the item, “ALBUMS,” is highlighted. Thehighlighted item can be acted upon by using the soft buttons, or anotherbutton, as discussed below. The current item can be changed by usingScroll Up button 128 and Scroll Down button 130 to move the highlight upor down, respectively, throughout a list of displayed items.

Icons are used to provide additional visual cues for an item. In FIG. 1,each of the categories has a category icon to the left of it. Thecategory icon, which may not be distinctly visible in the Figure,illustrates a first box connected by lines to additional boxes below thefirst box. The icon depicts a hierarchy and illustrates the property ofcategories, i.e., that categories can contain additional categories,songs or other items.

FIG. 10 illustrates a sequence of display screens describing how tonavigate to lower levels.

In FIG. 10, library category screen 150 shows the display as it appearswhen the user depresses library button 116 of FIG. 9. A preferredembodiment of the device uses 4 first-level categories. These are“Albums”, “Artists,” “Styles” and “Play Lists”. Each of these categoriescan “contain,” or be associated with, other categories, songs, or items.

Note that in library category screen 150 ALBUMS is currentlyhighlighted. By depressing soft button 112 of FIG. 9, the “open” commandis performed on the highlighted category, as indicated by the labelingof soft button 112 and soft button function description area 152 of FIG.10.

Lists screen 154 is displayed as a result of a user opening the Albumscategory of library category screen 150. Lists screen 154 shows itemswithin the Albums category such as commercial albums of multiple songsfrom a record label, pre-made lists or collections created by a user, orother predefined lists or collections of songs or recordings.

In FIG. 10, lists screen 154 shows each item as a list of songs. This isshown visually by the icon to the left of each item which depicts aminiature list. Possible soft button commands are “Close”, “Open” and“Queue”. These commands correspond to soft buttons 110, 112 and 114,respectively. If the user selects the Close command, the display revertsto library category screen 150. If the user selects the Open command,the display shows tracks screen 156. Alternatively, the user can selectthe Queue command to instruct the device to place all the songs from theselected (i.e., highlighted) list into the play list for eventualplayback. Yet another option allows the user to press play button 122 ofFIG. 9 to cause any currently-selected songs or a list of songs (e.g.,an album) to immediately be played.

Returning to FIG. 10, tracks screen 156 shows that a single song called“JukeBox Demo” is in the list. The list is also called JukeBox Demo asshown in lists screen 154. Tracks screen 156 shows possible softcommands assigned to buttons, namely “Close”, “Details” and “Queue.” TheClose button performs the same function as before—it returns the user tothe previous screen which, in this case, is lists screen 154. The usercan also select the Details command to cause details of the song JukeBoxDemo to be displayed in details screen 158 as shown in FIG. 10. The usercan select the Queue command by soft button 114 to enter the selectedsong into the play list queue. As before, the user can also depress playbutton 122 of FIG. 9 to cause immediate playback of the selected song.

Details screen 158 shows information about the selected song includingthe name of the song, album (or list) name containing the song; thetrack number, if applicable, and track duration. Note that otherinformation can be included. The user can preview the song, close theDetails screen to return to the Tracks screen or queue the song on theplay list queue.

The device provides the ability to “preview” audio files even while acurrent song, or playlist, is being played. When a user chooses topreview an audio file, the audio file is played for about 10 secondswhile any currently-played file or playlist is suspended. Afterpreviewing is complete, the suspended file or playlist resumes playback.In other embodiment, the preview duration can vary, or be stopped byuser selection.

FIG. 11 illustrates associations among items.

In FIG. 11, song 168 is one of many songs stored in the device.Categories such as albums 160, artists 162, play lists 164 and genres166 each include sub-categories. For example, albums 160 includes thenames of various albums. Songs are associated with albums, genres andplaylists. Such association can be by using pointers, a data structureincluding items to be associated, etc. “Association” as used herein,includes a first item associated with a second item; and the second itemassociated with the first item. In other words, albums can be associatedwith one or more songs in the database of the device so that anautomated search to find all songs associated with an album is easier.The direction of arrow pointers in FIG. 11 is not intended to limit themanner of associations among items in the present invention.

Similar to albums, the category of artists 162 includes names ofartists, or performers, of songs. Each artist name is associated withone or more songs in the database. Playlists 164 includes names ofplaylists. These are collections of songs that can be defined by theuser, the device manufacturer, or others. Each playlist can beassociated with one or more songs. Genres 166 includes various styles ofmusic which are associated with one or more songs in the database. Notethat items can exist without being associated with a song. Also, itemscan be associated with other items as where an artist name is associatedwith the albums containing the songs that the artist has created.

Although not shown in FIG. 11, items can have additional information,such as properties, details, etc., associated with the item. Forexample, a song can have information such as play time, artist name,artist album, copyright owner, etc., associated with the song.

FIG. 12 illustrates display screens used to search for a song or otheritem.

In FIG. 12, screen 180 is the initial library screen, as discussedabove. If the user invokes the Search command (via the appropriate softbutton) with Albums selected then screen 182 is displayed. Note that thesearch function can be applied to any of the categories. The user candepress the Plus or Minus soft buttons to cycle through the alphabet andchange the character in the current location as indicated by the cursor.The cursor position is changed by using the scroll up/scroll downbuttons 128 and 130, respectively, of FIG. 9. As each letter is enteredthe letters are compared and the nearest match of the stored albums'names is displayed as shown in screen 184. When the desired match isdisplayed the user selects the Go! command.

Screen 186 shows the result of selecting the Go! command. A list ofalbums is displayed with the matched album centered and selected. Theuser can close, open or queue the album as discussed above.

FIG. 13 illustrates details of different items.

In FIG. 13, screen 200 illustrates details displayed as a result ofselecting the “Details” command from soft button 1A track is selected.Screen 200 shows that details of the track “Jukebox Demo” shows the nameof the album that the track resides on, the creator, or copyright owner,of the track, and the playing time of the track.

Screen 202 illustrates details of an item on the active queue list.Items are placed onto the active queue list by selecting the “Queue”command when an album, song, track, or other item is selected, asdiscussed above. For example, screen 204 shows the active queuelistwhere the track “Jukebox Demo” is selected. By invoking the “Details”command screen 202 is brought up to show details of the Jukebox Demotrack.

As shown in screen 202, the Detail screen shows what track number theselected track is, which album the track is from; the creator, orcopyright owner, of the track, and the title of the track. Additionally,the details for an item on the queue list also show playback settings.These are shown by two-letter abbreviations at the bottom of the screen.The settings are as show in Table I, below. TABLE I EA EnvironmentalPreset EQ Parametric EQ HS Headphone Spatialization TS Time Scaling 4SFour Channel Speaker Sound (only if speakers are connected)

These settings have their common meanings, as is known in the art. Notethat the setting 4S is not shown in screen 202 as it is not currentlyactive.

FIG. 14 illustrates the Nomad Jukebox coupled to a host computer system.

In FIG. 14, device 300 (e.g., the Nomad Jukebox) is coupled to hostsystem 302. In a preferred embodiment host system 302 is a personalcomputer, such as an IBM-PC compatible computer. Host system 302includes a user interface having display 304 and user input devices suchas keyboard 306 and mouse 308. In other embodiments the host system neednot be a full computer system. Any type of processing system having auser interface is possible. For example, it is possible to couple thedevice to a laptop computer, game console, web-enabled television, orany consumer electronic device or digital platform, in general. The hostuser interface need not provide a display and can be much more minimalthan the keyboard and mouse shown in FIG. 14. A preferred embodiment ofthe invention uses a Universal Synchronous Bus (USB) connection but anytype of connection such as IEEE 1394 (FireWire), Ethernet, Serial Port,etc. can be used. A wireless (i.e., optical or radio frequency)connection can be used.

Once device 300 is coupled to host system 302, a user of host system 302can launch a bridge interface to allow for the transfer of files betweendevice 300 and host system 302. In a preferred embodiment, once thebridge interface is launched, the controls of device 300 are inoperable.The user interface of host system 302 is used to operate the bridgeinterface to transfer files.

The invention has now been described with reference to the preferredembodiments. Alternatives and substitutions will now be apparent topersons of skill in the art.

1. A method of navigating through a plurality of tracks, the methodcomprising: accessing a first hierarchy level of metadata associatedwith the plurality of tracks; accessing a second hierarchy level of themetadata in response to a selection from the first hierarchy level; andeither accessing a third level of the hierarchy in response to theselection from the second hierarchy level or selecting at least onetrack from the second hierarchy level, wherein data pertaining torespective ones of the first, second, and third hierarchy levels arepresented in sequential screens, each sequentially presented screenreplacing the previously presented screen.
 2. The method as recited inclaim 1 wherein the plurality of tracks are music tracks.
 3. A methodfor accessing tracks as recited in claim 1, wherein in the first screenthe selections available in the listing are one of listings of genretype, listing of album names, listing of artist names selectedpreviously.
 4. A portable media player having a plurality of tracksstored therein, the media player comprising: a display screen; a userinterface; and a processor configured to present sequentially a firstand second display screen on the display of the media player, theplurality of tracks accessed from a hierarchy of metadata, the hierarchyhaving a plurality of categories, subcategories, and items respectivelyin descending levels of the hierarchy; wherein the portable media playeris configured to: select at least one member from a first level of thehierarchy in the first display screen of the portable media player;display an expansion of the selected member in a listing presented inthe second display screen; and select a second member from the expansionin the second display screen; and display an expansion of the selectedsecond member a third display screen; and accessing at least one trackbased on a selection made in the second display screen.
 5. The portablemedia player as recited in claim 3 further configured to display anexpansion of the selected second member in a third display screen andwherein accessing at least one track is based on a selection made in thethird display screen.